* feat: add RBAC smoke test for group-based conditional region row filtering

Add a test that verifies group-based conditional row filtering:
- region_test cube backed by users table (id, city, count)
- region_test_view with an access policy for user_group that
  conditionally applies a row filter based on region_group membership
- region_user (user_group + region_group): sees only San Francisco rows
- region_user_no_filter (user_group only): sees all rows

The access policy checks security_context.auth.groups for region_group
membership. If present, it filters rows by the user's region attribute.
If absent, it grants allow_all (no row filter).

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* fix: use line_items table, group-based conditions, and MEASURE syntax

- Switch region_test cube to use public.line_items table to avoid
  cross-contamination from the users cube's RBAC city filter
- Add cube-level allowAll access policy so view policies can layer
  on top correctly
- Use group-based (user_group) policies with conditions to check
  hasRegionFilter user attribute for conditional row filtering
- Use MEASURE() syntax for aggregate count queries
- Both users have groups only (no roles needed) — view policy uses
  group: 'user_group' with conditions for mutual exclusivity

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* feat: allow security_context evaluation at rowLevel in access policies

Enable security_context to be used directly at the rowLevel property
of access policies, allowing the entire filter structure to be
controlled dynamically based on the user's security context.

Changes:
- CubePropContextTranspiler: add special handling to transpile
  rowLevel/row_level when its value is an expression (not an object
  literal), wrapping it in an arrow function with securityContext
- CubeValidator: accept Joi.func() as alternative for rowLevel,
  alongside the existing RowLevelPolicySchema object
- CompilerApi: resolve rowLevel via evaluateContextFunction when it
  is a function, and process the returned raw filters through a new
  evaluateRawFilter method that handles uncompiled member references
- Update test to use the cleaner syntax where security_context
  controls the rowLevel structure directly via groups.includes()

This enables patterns like:
  rowLevel: security_context.auth?.groups?.includes('region_group')
    ? { filters: [{ member: 'col', operator: 'equals', values: ... }] }
    : { allowAll: true }

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* refactor: convert region_test_view from JS to YAML

Replace the JS view with a YAML view that uses two mutually exclusive
conditions on the user_group access policy:
- hasRegionFilter (truthy) -> filters by allowedProductIds
- noRegionFilter (truthy) -> allow_all

Users carry complementary boolean attributes so the YAML conditions
(which only support truthy checks, not comparisons or negation) can
distinguish the two cases without policy overlap.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* refactor: use group-based policies instead of attribute-based conditions

Replace attribute-based conditions (hasRegionFilter/noRegionFilter) with
pure group-based policy scoping:
- group: region_group — row filter by allowedProductIds
- group: user_group — allow_all

Each user belongs to exactly one group so only one policy matches,
avoiding the union overlap problem without needing conditions.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* refactor: revert core changes, use conditions with groups.includes() check

Revert all changes to cubejs-schema-compiler and cubejs-server-core.
Use standard access policy conditions to check security context groups:

- Two mutually exclusive user_group policies with conditions:
  - if: security_context.auth?.groups?.includes('region_group')
    → filters by allowedProductIds
  - if: !security_context.auth?.groups?.includes('region_group')
    → allowAll

- region_user has both ['user_group', 'region_group'] and is
  correctly filtered because the condition routes to the filter
  policy, not the allowAll policy.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* refactor: convert region_test_view to YAML with group-scoped policies

Replace JS view with YAML view using two group-scoped policies:
- group: region_group — filters by allowedProductIds
- group: user_group — allow_all

Users belong to exactly one group to avoid the union-overlap problem
where allow_all would override the filter. No core changes.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* fix: use JS view with groups.includes() conditions for both-groups support

A user with both user_group and region_group must be filtered by
region_group. This requires mutually exclusive conditions checking
groups.includes('region_group') — which needs JS (not YAML, since
the YAML Python parser cannot express negation).

Single user_group policy with two condition branches:
- groups.includes('region_group') → filter by allowedProductIds
- !groups.includes('region_group') → allowAll

No core changes. region_user now has ['user_group', 'region_group']
and is correctly filtered.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

* feat: add not/and/or support to YAML Python parser, convert view to YAML

Add support for Python boolean operators in the YAML expression parser:
- not → JS ! (unary negation)
- and → JS && (logical AND)
- or  → JS || (logical OR)

This enables YAML access policy conditions like:
  if: "{ not (security_context.auth.groups and security_context.auth.groups.includes('region_group')) }"

Convert region_test_view from JS to YAML using the new operators
for null-safe group membership checks in conditions.

Co-authored-by: Pavel Tiunov <pavel.tiunov@gmail.com>

---------

Co-authored-by: Cursor Agent <cursoragent@cursor.com>